1. Technical Field
The invention relates to locking mechanisms. More particularly, the invention relates to a JavaScript enhancement that increases the performance of the JavaScript by avoiding the use of locking mechanisms in multi-threaded sessions.
2. Description of the Prior Art
Multi-threaded technology is well known and well used in the computer programming and application development industry. In particular, multi-threaded programming is permitted and supported by the World Wide Web (Web) and particularly within the JavaScript language. Web browsers and Web servers communicate with each other using multi-threaded technology to deliver information, whether in graphical format or in other media, to end users. In a multi-threaded situation, where more than one task is performed simultaneously, it is possible for more than one thread to try to access a same encapsulated programming object, thus creating problems if that object's state is being changed by one of the sharing threads.
Locking mechanisms are known in the art to lock an object by a thread requesting access to that object, thereby preventing it from being accessed by another thread until the first thread is done with the object. However, locking mechanisms can be expensive because they add overhead before and after the critical code sections that acquire and release the lock, and because in the case of contention for a lock among multiple threads, they incur further overhead.
S. Barlow, E. Leaphart, Jr., G. V. Strazds, and C. Rudbart (herein referred to as Barlow et al), Systems and Methods for Locking Interactive Objects, U.S. Pat. No. 6,275,935 (Aug. 14, 2001) disclose an object locking system for preventing unauthorized modification of interactive objects having one or more object states. An object designer interactively assigns one or more object behaviors to each object state. An end user of the object displays the object behavior associated with an object state, typically by invoking the object state with an input device. A lock behavior provides a way of locking an object behavior or aspect of an object. The object designer sets which aspects of an object are to be locked, and a lock controller prevents active access to those aspects accordingly. In addition, an object can be locked based on a password or based on the location of display of the object. Barlow et al do not teach locking an object under an atypical situation where an object is not owned exclusively by the current thread in a JavaScript engine. A. I. Wang, Enabling Multiple Runtime Processors in an Interpreter-Based Embedded Scripting System, U.S. Pat. No. 6,292,936 discloses an interpreter-based embedded scripting environment that includes multiple runtime processors executed by a computer. Each of the runtime processors processes their respective corresponding intermediate sources derived from an original input source in a synchronous manner. One or more of the respective corresponding intermediate sources includes a synchronizer token that provides synchronization among the runtime processors. Using the synchronizer token, an execution sequence of the original input source is maintained. Nowhere does Wang teach or even suggest locking an object under an atypical situation where an object is not owned exclusively by the current thread in a JavaScript engine.
C. Braband, A. Moller, and M. I. Schwartzbach, The <Big Wig> Project, BRICS, Department of Computer Science, University of Aarhus, Denmark {brabrand,amoeller,mis}@ brics.dk disclose the results of a project that aimed to design and implement a high-level domain-specific language for programming interactive Web services. They disclose that a mechanism is needed to discipline the concurrent behavior of the active threads. They continue to say that a simple case is to control access to the shared variables, using mutex regions or the readers/writers protocol. Another issue, they put forth, is enforcement of priorities between different session kinds, such that a management session may block other sessions from starting; a final example being event handling, where a session thread may wait for certain events to be caused by other threads. Braband et al disclose that they deal with all of these scenarios in a uniform manner based on a central controller process in a runtime system. However, nowhere do Braband et al teach or even suggest providing a simple and elegant enhancement that avoids use of locking mechanisms that otherwise create a lot of overhead.
It would be advantageous to increase performance of a JavaScript engine by avoiding the unnecessary use of locking mechanisms in multi-threaded sessions.